Contemporary browsers and other applications allow plug-ins, which in general comprise hosted software code that interacts with the hosting browser/application to provide some desired functionality. An important reason for using plug-ins is related to security, because the hosting browser limits the actions that the hosted code, which is generally untrusted, can perform.
One such plug-in is Microsoft® Silverlight™, which provides a platform that allows for development and hosting of rich web applications that typically include animation, vector graphics and/or media (e.g., audio/video) content playback. Windows Presentation Foundation (WPF) is another such platform.
In general, to play media on such a platform, the platform provides APIs that the hosted application code calls to point the media element at specific media content, e.g., by identifying a particular URI location on a server that corresponds to a container in which the media content is packaged. The platform then spawns network requests to start downloading the media. The platform parses the media content by unpacking it to extract the media content streams to provide them to a media pipeline for playback.
While such a plug-in-based model works very well for its intended purpose, there are a number of drawbacks with this design. For one, the platform needs to know each type of media container/file format so that it can extract and parse the contents; however, containers pack media streams in various, specific ways, whereby the unpacking needs to be done in specific ways. At present, such unpacking logic is hard coded in the platforms, whereby new container formats, which appear fairly regularly, need to be supported through platform updates.
Another drawback to this plug-in/platform model is that the protocols/transport mechanism used to obtain the content are limited to those the platform knows. Proprietary or other protocols/transport mechanisms cannot be used, which limits the content provider's flexibility in providing the media content.